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Software Product Line Engineering (SPLE) is a software engineering paradigm that focuses on reuse 
and variability. Although feature-oriented programming (EOP) can implement software product line 
efficiently, we still need a method to generate and prove correctness of all product variants more ef¬ 
ficiently and automatically. In this context, we propose to manipulate feature modules which contain 
three kinds of artifacts: specification, code and correctness proof. We depict a methodology and a 
platform that help the user to automatically produce correct-by-construction product variants from 
the related feature modules. As a first step of this project, we begin by proposing a language, GEML, 
allowing the developer to write such feature modules. This language is designed so that the artifacts 
can be easily reused and composed. GEML files contain the different artifacts mentioned above. 

The idea is to compile them into EoCaLiZe, a language for specification, implementation and formal 
proof with some object-oriented flavor. In this paper, we define and illustrate this language. We also 
introduce a way to compose the feature modules on some examples. 

1 Introduction 

Software Product Line Engineering (SPLE) is a paradigm used to develop software-intensive systems 
that share common assets mm. In SPEE, a feature is used to represent a characteristic behavior as a 
unit of functionality of the software product line (SPE) fT]. Given a set of features, the configuration of 
a SPE is constructed by composing the features. Eollowing generative programming mechanisms |41, 
the respective product variant can be derived automatically from a feature selection and artifacts of each 
selected feature. The product generation may be realized through Eeature-Oriented Programming (POP) 
techniques Q, in which each feature is mapped to a feature module containing its artifacts. The product 
variant is synthesized from the artifacts of the involved feature modules. In this context, we demonstrate 
our approach that helps the developer to write feature modules containing their artifacts using a dedicated 
and generic language. 

Some authors proposed approaches for constructing product variants of a product line by reusing and 
synthesizing artifacts. Using design by contract ifT^ and adhering to POP techniques, Thiim proposed 
a proof composition approach and strategies to reduce the effort of verification by reusing partial proofs 
na m All. The PEATUREHOUSE framework, described in ||2l, enables the construction of a new 
program from existing programs using the structure of the SPE feature tree. Although the above methods 
can implement software product line efficiently and mostly automatically, we still need a method to 
generate and prove correctness of all product variants more efficiently and automatically. 

In this direction some advances have been proposed in the context of programming language meta¬ 
theory within the Coq proof assistant ifTOl ifTTI . However these tools are dedicated to a very specific 
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domain and still require an important expertise. 

To tackle the above limitations, we depict a methodology that helps the user to automatically produce 
correct-by-construction product variants. This methodology aims at being independent of any concrete 
target language but at first we focus and experiment with FoCaLiZe, a language used to specify, imple¬ 
ment and prove (http: //focalize. inria. fr). In this paper, we propose a language, called GFML 
(for Generic Feature Module Language) allowing the developer to write feature modules which contain 
three kinds of artifacts: specifications, code and correctness proofs. GFML is inspired from FoCaLiZe 
but sticks to a FOP approach and tries to reduce the developer’s effort. This language is designed so that 
the artifacts can be easily reused, composed and translated into different languages. 

In Section we first describe the background of our paper, in particular we present briefly FoCaL¬ 
iZe. Then in Section we illusfrafe our definition of feature module and a brief description of our 
language (GFML) used to write feature modules. In Section we illustrate the translation of GFML 
into FoCaLiZe. In Section we describe how to compose two feature modules by giving an example, 
and depict a composition framework for automatically generating correct-by-construction product vari¬ 
ants. In Section 1^ we review related work. Finally we conclude the paper and discuss future works in 
Section |7] 


2 Background 

2.1 Software Product Line 

In SPLE, a feature is a characteristic behavior specified as a unif of funcfionalify of a producf line |T!|. 
A sef of feafures, called a feature model, is often graphically depicted as a free, also called a feature 
diagram. In addition to the presentation of commonality and variability, a feature diagram also con¬ 
tains various relationships and additional constraints between features. The main relationships in feature 
diagrams are optionaFmandatory, altemative/or and implies/excludes. Because of visual aid, feature di¬ 
agrams are considered as standard representations that help the user to choose product configurations of 
a product line. In this work, we only focus on a simple form of feature diagrams (i.e. Figure that can 
illustrate optional features. 

Valid Configuration. A configuration of a product line is a 
set of features selected in the corresponding feature diagram. All 
the information such as relations and constraints inferred from the 
feature diagram is used to check the validity of the configuration. 

In our work, we only consider valid configurations. However, 
checking the validity of a configuration is out of the scope of this 
paper. Many checkers exist (e.g. [*511, |0) and we rely on them. As 
we start from valid configurations, we consider that the configu¬ 
rations contain all the features that are to be composed in order to 
build the final producfs. So fhe disfincfion befween mandafory and 
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Figure 1: Feafure diagram 
optional feafures is nof relevant here. 


2.2 Motivating Example 

As a running example, we consider the bank account product line 
described in ifTTll whose feature diagram is shown in Figure It 
illustrates a family of products allowing the management of bank 
accounts. The root feature BankAccount (BA for short) provides 



Figure 2: Feature diagram of bank 
account product line 
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the basic management of an account. It allows the bank storing the current balance and the amount 
of money added into or withdrawn from the account. A customer can withdraw more money from the 
account than available if it is within an over limit. The feature BA has three optional child features 
DailyLimit (DL for short), LowLimit (LL for short), Currency. The feature DL allows the bank to limit 
the amount of money withdrawn in a day while the other feature LL indicates that the bank only au¬ 
thorizes a customer to withdraw money from the account only if the amount is greater than a low limit. 
Related The feature Currency accommodates the management of currency. Finally, an optional feature 
Currency Exchange is established as a child of Currency to enable the calculation of currency exchange. 

2.3 Quick Presentation of FoCaLiZe 

This subsection presents briefly the technical background necessary to understand the section about the 
translation of GFML to FoCaLiZe. 

The FoCaLiZe (http: //focalize. inria.fr) environment provides a set of tools to describe and 
implement functions and logical statements together with their proof. A FoCaLiZe source program 
is analyzed and translated into OCaml sources for execution and Coq sources for certification. The 
FoCaLiZe language has an object oriented flavor allowing inheritance, late binding and redefinition. 
These characteristics are very helpful to reuse specifications, implementations and proofs. 

A FoCaLiZe specification can be seen as a set of algebraic properties describing relations between 
input and output of the functions implemented in a FoCaLiZe program. For writing code, FoCaLiZe 
offers a pure functional programming style close to ML, featuring strong typing, recursive functions, 
data types and pattern-matching. Proofs written using the FoCaLiZe proof language are sent to the 
Zenon prover which produces proofs that can be verified by Coq for more confidence f9i. The FoCaLiZe 
proof language is a declarative language in which the programmer states a property and gives hints to 
achieve its proof which is performed by Zenon. 

FoCaLiZe units are called collections. They contain entities in a model akin to classes and objects or 
types and values. Collections have functions and properties which can be called using the “! ” notation. 
They are derived from other units called species which specify and implement functions. 

A species defines a set of entities together with functions and properties applying to them. At the 
beginning of a development, the representation of these entities is usually abstract, it is precised later 
in the development. However the type of these entities is referred as Self in any species. Species may 
contain specifications, functions and proofs. More precisely species may specify a function or a property 
(with resp. signature, property keywords) or implement them (let keyword when a function is 
defined, proof of keyword to introduce a proof of a property). A let defined function must match 
its signature and similarly a proof introduced by proof of should prove the statement given by the 
property keyword. Statements belong to first order typed logic. 

As said previously, FoCaLiZe integrates inheritance, late binding and redefinition to ease reuse and 
modularity. Inheritance allows the definition of a new species from one or several other species. The 
new species inherits all the functions, properties and proofs of its parents. Some syntactical mechanisms 
are provided to prevent ambiguities. A species may provide a definition for a function that is only 
specified in its parents. It may also redefine a function when this one is already defined in a parent but 
in that case the signature is maintained (no overloading). Multiple inheritance comes with a late binding 
mechanism close to the one found in object oriented languages (even if the resolution is statically done 
by the compiler). 

A collection is a species where every specified function is defined and every property is proved 
(or explicitly admitted). Furthermore, in a collection, the concrete representation of entities is made 
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private and a programmer using the collection can only use its functions and properties according to the 
interface. Consequently building a collection from a species provides encapsulation. Species may have 
parameters which may either be collections or entities providing in that way parametric polymorphism. 
This parametrization will be intensively used in the translation of GFML to FoCaLiZe (see Section Q. 

For more details on FoCaLiZe please refer to the reference manual. A more thorough overview can 
be found in |j3|. 

3 Artifacts 

3.1 Feature Module 

We adhere to the FOP technique that suggests to map each feature to a separate feature module that 
implements the feature. In our context, each feature module consists of its artifacts; specifications, 
code and correctness proofs. Specifications are given as a set of expected properties or requirements. 
Technically these properties are logical formulas relating together some functions described only by 
their signature. Thus in our setting, a specification is close to an algebraic data-type. Code has to be 
understood here as the implementation of the functions introduced/declared in the specifications. We 
place ourselves in a functional programming setting. The proofs here concern the correctness of the code 
with respect to the specifications. 

• Specification artifact includes the function declarations and the properties. A function declaration 
or signature only describes the name of the function and the type of its arguments and result. A 
property is a (first order typed) logical formula. A new property is expressed by a new logical 
formula while a refining property refers fo exisfing properties of fhe parent feafure module and 
may add new premises and conclusions. 

• Code artifact consists of the definition of the concrete representation type r and the function 
definition/redefinitions df. The representation type is the concrete type associated to the abstract 
data-type specified in the specification artifact. It will be a concrete type (basic or complex types, d 
la ML) or a Cartesian product of concrete types. The representation type is unique for each feature 
module and can be also constructed from the existing representation type of parent. A function is 
defined/redefined after the representation type has been defined. 

• Proof artifact contains proofs pf. Each proof corresponds to a property. While writing the proof 
for a refining property, the mentioned properties of parent can be reused to support the proving 
process. 

We define a feature module fm as a 5-tuple: function declarations d, properties p, representation 
type r, function definitions/redefinitions df and proofs pf. 

fm= {d,p,r,df,pf) 


3.2 Description of GFML 

We propose a generic language, called GFML, to write these feature modules. Each feature module is 
embedded into a separate file .gfm. This language is suitable for all feature modules possibly containing 
three kinds of artifacts: specifications, code and correctness proofs. 

This language is inspired from EoCaEiZe, in particular the styles for writing specifications, code and 
proofs are common. GEME and EoCaEiZe mainly differ in the way to structure and organize information. 
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1 f_module BA 

2 signature over: int; 

3 signature balance: BA -> int; 

4 signature update: BA -> int -> BA * S; 

5 property update_succ_BA: all x : BA, all a : 

6 int, all r : BA * S = 

7 (balance(x) + a) >= over -> update (x,a) = r 

8 -> (balance(first(r)) = (balance(x) + a)) && 

9 (second(r) = success); 

10 representation = int; 

11 let balance(x) = x; 

12 let update(x,a) = 

13 if ((balance(x) + a) >= over) then 

14 ((balance(x) + a), success) 

15 else (x, no_success); 

16 proof of update_succ_BA = (by definition of 

17 update, balance); 


1 f_module DL from BA 

2 signature limitwithdraw: int; 

3 signature withdraw; DL -> int; 

4 property update_succ__DL: all x : DL, all a : 

5 int, all r : DL ^ S = 

6 refines BA!update_succ_BA(x, a, r) 

7 new premise: Hi 

8 new conclusion: (withdraw(first(r)) = 

9 withdraw(x) + a); 

10 property update no succ DL: all ... 

11 Representation — int* BA!representation; 

12 let withdraw(x) — second(x); 

13 let update (x, a) = let w_^= withdraw (x) in 

14 let rr = BA!update(x,a) in 

15 let n_b = first(rr) in 

16 let n_s = second(rr) in 

17 let n_w = w + a in 

18 if (a <= 0) then 

19 if ( (n_w >= limit__withdraw) && (ii_s ~ 

20 success)) then 

21 ((n_b,n_w),n_3) 

22 else (x,no_success) 

23 else ((n_b,w),n_s); 

24 proof of update_succ_DL = (by hypothesis H2 

25 definition of withdraw, update, make balance 

26 property BA!update_succ_BA); 

27 proof of update no succ DL = (by ...) ; 


(a) Module BA 


(b) Module DL 


Figure 3: Feature modules in GFML 

Our main objective in defining GFML is to propose a language close to FoCaLiZe that already allows for 
the three kinds of artifacts in a single setting but closer to the description of commonality and variability 
we can find in feature diagrams. As we will see in Section]^ the expression of a feature module is much 
simpler that its translation in FoCaLiZe. GFML is also inspired from design by contract applied to FOP 
as in ifTSll . In the same way, GFML syntax allows the programmer to focus in a GFML feature module 
on the modifications brought to the specifications or implementations of the parent. 


3.3 Examples 

Corresponding to the feature diagram of the bank account product line given in Figure the feature 
module BA implements the root feature BA. Feature modules DL, LL, and Currency are mapped from 
the features DL, LL, and Currency respectively. They have a common parent, i.e. the root module BA. 
Feature module CurrencyExchange corresponding to feature Currency Exchange, is a child of the module 
Currency. 

The root feature module BA, written with GFML, is shown in Figure This module includes three 
signatures: over - is over limit, balance - gets the current balance value of the account and update - up¬ 
grades the new value balance and also returns the status of the operation (success or no success, of type S 
whose definition is omitted here). The next part of the module BA contains the property updatesuccJiA 
(line 5) that specifies a customer can withdraw more money a from the account than available if the 
balance is within over. In that case, its status must be success. The primitive functions first and second 
used in this property are the usual projections of a Cartesian product. Then the representation type is 
defined as int (line 10), it means that an account is only represented by its balance. Then appear the 
definitions of the functions balance and update (lines 11-15). The proof of property updatesuccJiA 
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includes two proof hints: by definition of update and balance definitions. This means that the proof 
must be done by unfolding the definitions of both functions. 

Another example of GFML feature module is the module DL defined according to its parent feature 
module BA (Figure [^. Two new declarations limit ^withdraw and withdraw are added into the module 
(lines 2-3). The module introduces the constant limit .withdraw only declared at that point. It denotes 
the limit of withdrawn money in a day. It also introduces another function withdraw that returns, for 
an account, the current amount of withdrawn money in a day. The functions update, balance and over 
defined in the parent are also available in the present feature module. A new property update juccJ)L is 
obtained by modifying the property update.succJiA from the parent (line 6). This modification includes 
a new premise called HI (line 7) for short in the figure (but announced below) and a new conclusion (lines 
8-9). The premise HI is expressed as follows: 

r = update{x,a) ^ {a <= 0) ^ {all n_w w:int,all n.s:S, withdraw{x) =w && w + a = 

n_w && second{BA\update{x,a)) = n_s ^ {n_w >= limit .withdraw) && {n.s = success)) 

It states that the bank allows a customer to withdraw money only if the amount of withdrawn money in 
a day is greater than limit .withdraw (in this case w, n.w and limit .withdraw are negative numbers). The 
new conclusion states that this operation has to modify the account by updating the amount of withdrawn 
money. The representation type of module DL is defined as a Cartesian product of int (i.e. the concrete 
type associated with the amount of money withdrawn in a day) and the representation type of the parent 
(line 11). The functions withdraw and update are defined/redefined (lines 12-23). We can notice that in 
the redefinition of update the call to the parent function update is done with the parameter x, there is 
here an implicit conversion that will be inserted during the translation into FoCaLiZe. The proof of the 
property update.succJdL reuses the property update.succ.BA as a proof hint (line 26). All modifications 
and additions compared to the parent module BA are highlighted or underlined. 

4 From GFML to FoCaLiZe 

In this section, we illustrate the translation from GFML to FoCaLiZe. A GFML feature module is 
mapped into three FoCaLiZe separate species. The first species Inh contains all desired elements that 
are inherited in the child module. These elements can be function declarations, properties or predicates. 
A predicate, which is introduced with the keyword ‘logical let’ and named Leons, is associated with 
each property p found in a module. For example, the feature module BA written in Figure]^ is mapped 
to the species InhJiA (line 1). A predicate 1.cons.update .succ JiA (line 5) is associated with the property 
update juccJBA. In Figure]^ the species InhdDL of the child DL inherits the species Inh JiA of module 
BA (line 2). 

The FoCaLiZe inheritance mechanism allows the programmer to reuse the artifacts without any 
change (except for functions that can be redefined without changing its signature). But although some 
properties may be kept in the child module, others may be modified by adding new premises or/and new 
conclusions. In this last case, the FoCaLiZe inheritance mechanism is not sufficient. We have to use the 
parametrization facility to encode the right meaning. To tackle this limitation, we propose the second 
species Reu. that inherits the first species Inh.. It includes all desired specifications that are reused 
to describe new ones in the child. Each property specified in this species must have a corresponding 
predicate Leons in the first species Inh.. Instead of mentioning the property, we use this predicate 
for expressing new properties in the child. This trick is used because FoCaLiZe does not allow the 
modification of an inherited property in a species. For example, in Pigum^^species Reu JiA inherits 
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1 

species Inh DL = 


2 

inherit Inh BA; 


3 

sionature limit withdraw; int; 


4 

sianature withdraw : Self -> int; 


5 

end;; 


6 

species Reu DL = 


7 

inherit Inh DL; 


8 

property update succ DL : all x : Self, 

all a : 

9 

int, all r : Self * S = 


10 

Hi -> (1 cons update succ BA {x, a, r) 

/\ 

11 

(withdraw(first(r)) = withdraw(x) + a)); 


12 

end;; 


13 

species Imp DL (BA is Reu BA)= 


14 

inherit Reu DL; 


15 

representation = int*BA; 


16 

let withdraw(x) = second(x); 


17 

■let update (x, a) = let w = withdraw(x) in j 

18 

let rr = BAlupdate(x, a) in 


19 

let n b = first (rr) in 


20 

let n 3 = second(rr) in 


21 

let n w = w + a in 


22 

if (a <= 0) then 


23 

if ((n w >= limit^withdraw) && (r^s 


24 

success)) the& 


25 

((n b, n w), n s) 


26 

else (x,no success) 


27 

else ((n b,w),n s); 


28 

proof of update succ DL = by hypothesis 

H2 

29 

definition of 1 cons update succ BA, update. 

30 

withdraw property BA!update succ BA; 


31 

end;; 



1 

species Inh BA = 


2 

signature update ; Self -> int -> Self 

* S; 

3 

signature balance ; Self -> int; 


4 

signature over; int; 


5 

logical let 1 cons update succ BA (x : 

Self, a : 

6 

int, r ; Self * S) = 


7 

(balance(x) + a) >= over -> update (x. 

a) = r 

8 

-> (balance(first(r)) = (balance(x) + 

a)) it 

9 

(second(r) = success); 


10 

end;; 


11 

species Reu BA = 


12 

inherit Inh BA; 


13 

property update succ BA: all x : Self, 

all a : 

14 

int, all r : Self * S, 


15 

1 cons update succ BA(x,a,r); 


16 

end;; 


17 

species Imp BA = 


18 

inherit Reu BA; 


19 

representation = int ; 


20 

let balance(x) = x; 


21 

let update(x, a) = 


22 

if ((balance(x) + a) >= over) then 


23 

((balance(x) + a), success) 


24 

else (x, no success); 


25 

proof of update succ BA = by definition of 

26 update, balance, 1 cons update succ BA; 


27 

end;; 



(a) Module BA in FoCaLize (b) Module DL in FoCaLize 

Figure 4: Feature modules in FoCaLize 


the species InhfBA. It contains the property updatesuccJiA (line 13) that is related to the predicate 
Lcons-update^uccJlA in species Inh_BA. This predicate is reused to specify the refining property 
update-Succ-DL of module DL (line 10 of Figure [4b]). 

The parametrization mechanism in FoCaLize is used here to circumvent the fact that in FoCaLiZe 
when the representation type is fixed in a species P, it cannot be changed in any species which inherits 
P. So in order to build a new species that can reuse functions, properties, predicates and proofs that are 
defined for BA, we have to parametrize this species by an implementation of BA. Thus, when the DL 
feature is selected, the account is implemented as a pair containing a basic account of type BA and an 
integer corresponding to the new attribute, i.e. the amount of money withdrawn in a day. The implemen¬ 
tation of the functions balance and over are, in this context, just a call to the parent’s functions combined 
with the first projection. For example, species Imp_BA inherits species ReuJiA (line 18 of Figure |4a|) 
while species ImpfDL inherits species ReuJdL (line 14 of Figure |4b| ). A parameter BA encapsulates 
species ReuJBA (line 13 of Figure |4b|). It is used to call function update of module BA (line 18). In the 
proof of the refining property update JuccJdL, property updatesuccJBA of the parent BA is considered 
as a proof hint (line 30). Its associated formula l_consMpdate.succJiA is also a proof hint (line 29). Let 
us notice that Zenon, the FoCaLiZe prover has done all the proofs with the given hints. 

We can notice that the use of a language such as FoCaLiZe for implementing and verifying feature 
modules is quite complex. The proposed language GFML is a solution to write the feature modules 
together with their artifacts more easily. We have followed with success this translation scheme for 
all the features appearing on the feature diagram of Figure [^ For the moment, the translation is done 
manually. 
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Figure 5: Methodology 


5 Towards Feature Module Composition 

5.1 Methodology for composing artifacts 

The work previously described is the first step in the proposition of a methodology to help the user to au¬ 
tomatically produce correct-by-construction product variants from features selected in a feature diagram. 
This methodology is illustrated in FigureWe assume a SPL is described with a feature diagram. First, 
the developer writes the different feature modules with the GFML language. He uses the GFM Pre¬ 
compiler to translate his/her feature modules into FoCaLiZe to verify them (using the Zenon prover). 
Once this work has been done, the user - he may be different from the developer - chooses features from 
the feature diagram. Based on this selection, the corresponding configuration is determined. The related 
GFML feature modules are then sent to the GFM Combiner that will compose the feature modules of 
the configuration in order to obtain a composition feature module that will be translated into the desired 
product variant, which by composition is correct by construction. We expect this method to be indepen¬ 
dent from the target language which is required to be able to express specifications and code and also 
proofs (unless these ones can be automatically produced). 

In the next subsection we explain the main ideas of our composition mechanism on the running 
example. 

5.2 Composition of two feature modules: an example 

Some problems may appear when composing two feature modules, in particular conflicts may appear 
when synthesizing their artifacts. For example, which properties should be performed first? Which 
synthesized representation type will make less complex writing? To solve these problems, we suggest 
the user gives a composition order of the modules. In our work, we only consider the modified elemenfs 
such as refining properfies, represenfafion fypes, funcfion redefinifions or proofs of refining properfies. 

Similar fo module DL, module LL wriffen in Figure is exfended from fhe roof module BA. A 
new signafure limit Jow declares fhe low limif of fhe accounf. A new properly updateJiosuccJ^L is 
specified in line 7 and ifs proof is indicafed in line 16. However, we only consider fhe modifications fhal 
can cause conflicls when composing fwo modules. For example, lei us compose module LL wifh module 
DL. Their composition is fhe module LLJDL given in Figure]^ Properly update^uccJ^L of module 
LL includes fwo parts (lines 3-6 of Figure]^, lls highlighfed pari includes a new premise (shortened by 
H2), expressed as follows: 

r = update{x,a) ^ {{a >= 0) || {a <= limit Jow)) 
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1 f_module LL frcKi BA 

2 signature limitlow: int; 


3 property update_succ _LL1 all x : LL, all a T 

4 Int, all r : LL * S * 

5 refines BA!update_succ_BA(x, a, r) 

6 new premia: H2; 

7 property update no succ T.T.? all 


1 f_module LL_DL from LL, DL 

2 property update_succ_LL_DL : all x : LL_DL, all 

3 a : int, all r : LL_DL * s = 

4 refines DL!update_succ_DL(x, a , r ) 

5 new premise: r = update (x,a) -> 

6 ((a >= 0) II (a <= limit_low)); 


8 representation = BA!representation; 


9 let update(x,a) = 

10 if ((a >= 0) II (a <= limit_low)) then 

11 BA!update(x,a) 

12 else {x, no_3UCce3s); 


7 representation ~ DL !representation; 


13 proof of update_succ_LL = (by hypothesis Hi 

14 definition of update, balance property BA! 

15 update_succ_BA); 

16 proof of update no succ LL — (by ♦■■) ; 


8 let update(x, a) — 

9 if (a >= 0) II (a <= limit_low) '^h^# 

10 DL!update(x, a) 

11 else (x, no success); 


12 proof of update_succ_LL_DL = (by hypothesis Hi 

13 defintion of update, balance property DL! 

14 update_succ_DL, BA!update_succ_BA); 


(a) Module LL 


(b) Module LLJDL 


Figure 6: Composition of feature modules 


The premise specifies that a customer can withdraw money a from the account only if a is less than 
limitJow (in this case a and limitJow are negative numbers). The property update^uccJiA from 
the parent BA is its remaining part. Following the composition order, the composite property of two 
properties update juccJ^L and update JuccJ)L is synthesized by taking H2 first and then mixing with 
updatesucc-DL. It is named update^ucc-LLJ)L and embedded into a composition feature module 
LL_DL (lines 2-6 of Figure!^. Similarly, the composite representation type is synthesized in line 7. 
The function update is redefined (lines 8-11). The proof of the composite property updatesucc-LLJ)L 
reuses two properties updatesuccfDL and update juccJiA as its proof hints (lines 13-14) indicate. The 
highlighted parts of module LL (Figure]^ are the parts highlighted in module LLJDL (Figure [6bj). The 
other parts which are not highlighted in Figure]^ are taken from module DL. 


6 Related Work 


Recently, many authors focused on constructing and verifying program variants in SPL. Together with 
these, composition methods of feature artifacts are offered. In this subsection, we compare to some of 
them. 

Thiim et ah, in flSl . presents a composition approach where partial proofs are given in features and 
then composed to build the complete proofs for an individual product. The specifications are expressed 
using design by contract (131. The KrakatoaAVhy tool Ifl^ is used to generate proof obligations that are 
exported to the Coq proof assistant where proofs are done and verified. 

Our work is in line with the previous approach but it is dedicated to a functional setting whereas Thurn 
et al’s work involves object-oriented programs. Specification artifacts - expressed as logical formulas 
- found in a GFML feature module are close to contracts. For example, a refining property is close 
to a refining contracf since it includes a former specification and may add a new premise and a new 
conclusion. However in our work, each proof is complete. It is extended in a new proof in the result of a 
composition and thus in the resulting product variant. 

Another composition framework FEATUREHOUSE is offered in Q. Using the FST (feature struc¬ 
ture tree) model, existing artifacts can be composed to construct a new program. The artifacts must 
have tree structures. In contrast, we presented a framework that allows us to construct products from 
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the artifacts of the features selected by the user. We are interested in expressing feature compositions 
as algebraic expressions using composition operations for each kind of artifacts instead of relying on 
the tree structure. Similar ideas were mentioned in Q [161] . However, these approaches only focus on 
constructing products but do not mention how to verify them. 

Recent researches lITOl IfTTI had proposed some advances in feature composition in the context of 
meta-theory. However, these tools are dedicated to a very specific domain. Similar to Thum’s work, 
the products in these approaches are verified in Coq. In confrasf, implemenfing feafure modules inde- 
pendenfly of any concrefe fargef language is fhe purpose of our work. By proposing a generic formal 
language (GFML) for feafure module, fhe arfifacfs are easy fo reuse and synfhesize buf don’f belong fo 
any concrefe language. 

7 Conclusion 

In fhis paper we have described a firsf sfep fowards fhe production of a mefhodology allowing for fhe 
developmenf of correct-by-consfrucfion producf varianfs according fo a FOP paradigm. The confribufion 
is here fhe definifion of fhe language GFML allowing fhe developer fo wrife feafure modules confaining 
fheir specificafions, code and correcfness proofs. 

These modules are translafed fo FoCaLiZe for verificafion and also for obfaining OCaml operational 
code. Consequenfly fhe producf varianfs we are aiming af will be implemenfed in OCaml. GFML is 
here introduced to help the developer when he is writing the different feature modules, allowing him 
to describe the artifacts of a feature with respect to the artifacts of its parents. Realizing this directly 
in FoCaLiZe is a difficult task as it is exemplified by fhe franslafion scheme presenfed in a previous 
section. For fhe momenf, nofhing is implemented, all the examples found in this paper (all the possible 
configurations of the case study) have been obtained by a manual translation and composition. 

Next step is to provide an implementation for the GFML Pre-compiler that will automatically trans¬ 
late GFML to FoCaLiZe. Then composition of feature modules will be formally defined and imple¬ 
menfed in fhe GFML Combiner. 

Anofher imporfanf perspecfive is fo make our mefhodology independenf of fhe fargef languages. 
Regarding fhis poinf, an infermediafe sfep could be fo adapf our mefhodology and fools fo B or EvenfB 
where inherifance is nof available. 
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